FunnelFlux에는 세 가지 주요 내비게이션 관련 작업이 있습니다:
- 입구 링크 로딩:
/fts/ - 액션 링크 로딩:
/action/x - JS에 의한 페이지 조회 추적: POST to
/js/funnel
입구 링크는 매우 엄격하며 목적지로 라우팅하는 데 필요한 모든 데이터를 포함합니다 (UI에서 생성했기 때문에). 작동하면 지정된 곳으로 정확히 이동하며, 다른 맥락적 기록은 무시합니다. 입구 링크는 퍼널로의 독립적인 새로운 입구이기 때문입니다.
후자의 두 경우에서 FunnelFlux Pro 엣지는 사용 가능한 정보를 사용하여 사용자가 어떤 노드/페이지에 있는지 결정하고, 액션의 경우 어떤 연결을 따라갈지 결정합니다.
이들은 올바르게 구성되지 않으면 문제가 발생할 수 있으므로, 이 섹션에서는 JavaScript와 액션 링크가 현재 페이지와 출발 페이지/노드를 각각 어떻게 결정하는지 요약할 것입니다.
액션 링크 로직
액션 링크는 항상 방문자가 있다고 '생각하는' 노드에서 확장되는 번호가 매겨진 액션을 실행합니다.
퍼널을 테스트하고 탐색할 때는 퍼널 다이어그램을 고려하고 각 액션이 어떻게 한 노드에서 다음 노드로 이동하게 하는지 생각하면서, 현재 어떤 노드에 있는지(즉, 트래커가 알고 있는 위치)를 추적하는 것이 유용합니다.
페이지로 이동 > 액션 링크 클릭 > 새 탭에서 열림 상황을 생각해보세요. 원래 탭으로 돌아가 링크를 다시 클릭합니다. 이제 현재 알려진 노드 위치 이전의 노드에서 액션을 시작하고 있습니다.
두 번째 시나리오를 생각해보되, 액션 링크가 새 탭에서 열리지 않는 경우입니다. 그런 다음 브라우저의 뒤로 가기 버튼을 클릭하여 이전 페이지를 로드합니다. 이 페이지에 조회 추적 JS가 없다면, 트래커는 당신이 이 페이지로 다시 이동했다는 것을 알지 못합니다. 지금 액션 링크를 클릭하면, 다시 한 번 이전 노드에서 액션을 시작하고 있습니다.
두 경우 모두 트래커는 클릭의 출발 노드를 결정하여 이러한 반복 클릭을 감지할 수 있는 메커니즘이 필요합니다.
레퍼러 처리
액션 링크를 로드할 때 우리의 엣지는 레퍼러를 확인합니다.
이 레퍼러에 VID가 포함되어 있다면, 엣지는 이제 방문자 세션을 알게 됩니다(쿠키 없이도).
이 레퍼러에 전체 페이지 URL이 포함되어 있다면, 트래커는 이제 그 URL을 퍼널의 알려진 노드/페이지와 대조할 수 있으며, 이전에 방문한 페이지와도 대조하여 클릭이 이미 방문한 페이지에서 왔다는 것을 확인할 수 있습니다(클릭스루가 존재하기 위한 필수 이벤트).
레퍼러에 n=NODE_ID 매개변수가 URL에 포함되어 있다면, 트래커는 이제 페이지 URL 매칭에 의존하지 않고 정확하게 출발 노드를 결정할 수 있습니다. 이는 더 구체적입니다. 같은 페이지가 동일한 퍼널에서 여러 번 사용될 수 있거나(다른 노드 ID로), 페이지가 iFrame에 포함되어 있어 부모 URL과 따라서 레퍼러가 로드된 페이지를 나타내지 않을 수 있기 때문입니다.
이것이 우리의 JavaScript에 두 가지 도우미 함수가 있는 이유입니다:
하나는 페이지의 <meta name="referrer"> 태그를 확인하고, 있다면 그 값을 no-referrer-when-downgrade로 업데이트하고, 없다면 생성합니다.
두 번째 함수는 현재 페이지 위치를 다시 작성하여 방문자 ID와 현재 노드 ID를 URL에 포함시켜, 전체 레퍼러 값이 액션 링크 핸들러에 매우 유용한 정보를 제공하도록 합니다.
이를 고려하면, 링크에 rel="noreferrer" 속성을 추가하는 것은 피해야 합니다. 이는 무의미한 일입니다 -- 자신의 추적 시스템에서 정보를 숨기는 것이니까요!
루트 도메인에 호스팅된 페이지와 관련된 뉘앙스
전체 레퍼러가 전달되지 않을 때 흥미로운 뉘앙스가 발생할 수 있습니다.
https://domain.com(즉, 루트 도메인/홈페이지)에 초기 랜딩 페이지 A가 있고, URL이 https://domain.com/some-page/인 두 번째 페이지 B로 연결되는 퍼널을 고려해보세요.
브라우저에서 사용자는 페이지 A를 로드하고 성공적으로 페이지 B로 이동할 것입니다.
하지만 페이지 B에서 전체 레퍼러가 전달되지 않으면, 다음 액션 클릭은 축소된 레퍼러(호스트 이름만)를 전달할 수 있습니다. 그러면 우리의 엣지는 "domain.com"에서 발생한 것처럼 보이는 클릭을 보게 됩니다.
특이하게도, 사용자가 루트 도메인을 페이지로 사용했기 때문에, 이 레퍼러는 이전 랜더의 알려진 URL/경로이므로, 트래커는 주어진 정보로 이것이 실제로 페이지 A에서의 반복 클릭이라고 정당하게 판단할 것입니다.
이는 페이지 A > 클릭 > 페이지 B > 클릭 > 페이지 B > 클릭 페이지 B의 리디렉션 루프로 이어집니다.
직접 URL 매개변수 삽입
우리의 JS 도우미 함수 중 또 다른 하나는 href에 /action이 포함된 페이지의 <a> 요소를 감지한 다음 다음을 삽입합니다:
...&vid=VISITOR_ID&rn=CURRENT_NODE_ID
이 경우, 직접 지정된 URL 매개변수가 우선순위를 가지므로 레퍼러 정보는 사용되지 않습니다.
레퍼러와 URL 재작성 함수가 유용할 수 있다고 주장할 수 있지만 - 그렇지 않습니다.
사용자가 페이지에 JS 코드를 추가할 수 있지만 다음 페이지로 리디렉션하기 위해 단순한 <a> 요소를 사용하지 않는 상황이 많습니다. <a> 요소가 있지만 다른 페이지로 직접 링크하여 해당 URL에 매개변수를 삽입할 수 없는 경우도 있습니다. 액션 URL로의 리디렉션도 JavaScript에 의해 관리될 수 있으며, 이 경우 사용자는 거의 입력이나 동적 제어를 할 수 없습니다.
어떤 경우든, "rn" 매개변수는 우리의 엣지에 클릭이 해당 방문자에 대한 특정 노드에서 오고 있음을 명시적으로 지정합니다. 이는 신뢰할 수 있는 추적을 보장하는 가장 강력한 방법입니다.
액션 링크로의 리디렉션이 단순한 <a> 요소를 포함하지 않고 JavaScript 조작을 포함하는 고급 사례에서는, 우리의 조회 추적 JS에서 onDone() 함수를 사용하는 것을 추천합니다.
이를 사용하여 현재 노드 ID와 방문자 ID를 얻은 다음 리디렉션을 제어하는 함수에 이를 삽입할 수 있습니다 > 수동으로 이전 URL 매개변수를 액션 URL에 추가하여 동일한 이점을 제공합니다.
기본 액션 매개변수
이들은 퍼널 빌더에서 "액션 링크 가져오기" 컨텍스트 메뉴 항목을 사용할 때 토글할 수 있습니다.
이들은 퍼널과 노드에 특정해야 하므로 여기에서만 사용할 수 있습니다.
이 토글은 생성을 위한 것일 뿐이며, 퍼널/노드 자체에 특정 효과를 적용하지 않습니다.
이 URL들은 다음과 같이 기본 퍼널과 노드 ID를 선언합니다:
https://USER_DOMAIN/FUNNEL_ID/ORIGINATING_NODE_ID/action/number
이 값들이 오버라이드가 아니라는 점을 주목하는 것이 중요합니다. 이들은 VID 값을 알 수 없는 액션 링크 요청, 즉 새로운 또는 알 수 없는 방문자에 대해서만 사용됩니다.
따라서 이들은 시크릿 창에서 작동하지만, 맥락 없는 일반/범용 액션 링크는 작동하지 않을 것입니다.
99%의 경우 이러한 폴백 매개변수는 사용되지 않지만 - 유용하거나 중요한 몇 가지 시나리오가 있습니다:
- 제3자를 통해 리디렉션한 후 해당 제3자에 설정된 리디렉션 URL로 돌아가는 양식 제출을 할 때. 여기서는 제어할 수 없는 무작위 홉 때문에, 일반 액션 링크를 사용하면 로드될 때 유용한 레퍼러 정보가 없을 가능성이 높습니다(무작위 제3자 시스템의 정보만). 엣지는 VID를 결정하기 위해 쿠키만 사용할 수 있을 것입니다(신뢰할 수 없음!), 따라서 기본 매개변수는 적어도 사용자를 예상된 목적지로 보내는 데 중요할 것입니다. 이는 세션이 손실되고 원래의 퍼널 입구와 연결이 끊어지더라도 마찬가지입니다. 제3자가 URL 매개변수를 수집하고 전달할 수 있다면 좋겠지만, 많은 경우 이는 불가능합니다...
- 사용자를 어떤 페이지로 보내 액션 링크를 클릭해야 하지만, 어떤 이유로 레퍼러/데이터 전달을 돕는 우리의 JS를 삽입하기 위해 페이지 코드를 제어할 수 없는 경우
- 사용자가 알려진, 추적된 페이지에서 다른 페이지로 이동한 다음 알려진 페이지로 돌아올 때 -- 예를 들어, 웨비나 흐름을 통해, 세션 추적을 잃을 가능성이 있지만 여전히 일부 최종 액션/클릭을 추적하고 방문자가 의도한 목적지로 리디렉션되도록 하고 싶은 경우
다시 말해, 이러한 액션 링크는 추적을 강력하게 만들기 위한 제어권이 없고 레퍼러/쿠키/데이터 전달의 신뢰성이 전혀 없을 것으로 예상되는 모든 짜증나는 상황에서 도움이 됩니다. 하지만 여전히 사람들이 나중에 당신이 제어하는 링크를 로드하기를 원합니다.
JavaScript 페이지 조회 추적 로직
우리의 JS를 통한 페이지 조회 추적 이벤트는 두 가지 데이터 소스만 가집니다 - 현재 URL(및 쿼리 문자열)과 포함된 속성들입니다.
URL 매개변수는 항상 우선순위를 가집니다. 이렇게 하면 페이지가 선택된 기본 ID로 JS를 포함할 수 있지만, 우리의 UI에서 생성된 입구 링크는 항상 예상대로 추적됩니다. 이는 이러한 값들을 재정의함으로써 가능합니다.
직접 링크의 경우, 쿼리 문자열 URL 매개변수가 JS 기본값을 재정의합니다.
리디렉션 링크의 경우, 결과 페이지는 그러한 매개변수 없이 로드되지만 삽입된 vid=VISITOR_ID 값이 있습니다.
이 VID는 JS POST 요청에서 전달되어 사용자가 이동하고 있는 이미 알려진 노드 ID를 반환하며, 이는 JS 기본값을 재정의합니다.
다음은 몇 가지 다른 시나리오와 그 결과 동작입니다:
- 리디렉션 링크가 페이지를 로드하는데, 이 페이지에는 JS가 있지만 포함된 기본값이 없습니다. 여기서 VID가 URL에 존재하여 사용되며, 페이지의 URL이 현재 페이지를 결정하는 데 사용됩니다. 이는 리디렉션이 이동한 목적지와 일치할 가능성이 높아, 추가 페이지 조회가 생성되지 않습니다(중복 제거)
- URL 매개변수가 없고 포함된 매개변수가 설정되지 않은 JS로 페이지가 로드됩니다. 퍼널 ID가 항상 전달되어야 하므로 조회 추적이 실패합니다 -- 세션을 결정하기 위한 VID가 있는 경우에만 작동할 것이며, 이는 현재 퍼널 ID를 포함할 것입니다.
- 리디렉션 링크가 현재 세션/퍼널과 일치하지 않는 포함된 매개변수가 있는 JS가 있는 페이지를 로드합니다. 이 경우 VID가 알려지고 우선순위를 가지므로 퍼널은 변경되지 않습니다. 예상된 페이지에 대한 조회는 이미 리디렉션에 의해 생성되었으며, JS 조회 이벤트는 자동으로 URL 매칭으로 추적될 것입니다. JS가 리디렉션이 제공한 페이지와 일치하지 않는 페이지 ID를 지정하면, 선언된 페이지 ID가 현재 퍼널에 존재하는 경우 별도의 이상한 조회를 발생시킬 수 있습니다(그렇지 않으면 오류가 발생할 것입니다)
- URL 매개변수가 없습니다. 포함된 매개변수가 사용되지만 현재 퍼널에 존재하지 않는 페이지 ID가 지정되었습니다. 조회가 추적되지 않을 것입니다.
- URL 매개변수가 없습니다. 포함된 매개변수가 선언된 퍼널 ID에 존재하지 않는 노드 ID를 사용합니다. 조회가 추적되지 않을 것입니다.
- URL 매개변수가 없습니다. 페이지 ID가 있지만 현재 URL이 해당 페이지 ID와 일치하지 않습니다. 엣지는 URL 매칭을 무시하고 페이지 ID를 존중할 것입니다. 이를 통해 iframe/임베딩이 예상대로 작동할 수 있습니다.